Internet Message Extensions (822ext) Charter Chair(s): Gregory Vaudreuil Applications Area Director(s) Brewster Kahle Erik Huizer Mailing lists: General Discussion:ietf-822@dimacs.rutgers.edu To Subscribe: ietf-822-request@dimacs.rutgers.edu Archive: ietf.cnri.reston.va.us:~/ietf-mail-archive/822ext/* Description of Working Group: This Working Group was chartered to extend the RFC 822 Message format to facilitate multi-media mail and alternate character sets. RFCs 1341 and RFC 1342 document the Multi-Media Extensions for Internet Mail. The Working Group will work to progress MIME to Draft Standard status and provide a forum for the review of standards track content-type specifications and the review of character set extensions to MIME. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Aug 92 Dec 92 Japanese Character Encoding for Internet Messages Feb 93 Apr 93 Mechanisms for Specifying and Describing the Format of Internet Message Bodies Mar 93 New MIME (Multipurpose Internet Mail Extensions) Part Two: Message Header Extensions for Non-ASCII Text Apr 93 Apr 93 The Content-MD5 Header Apr 93 New The text/enriched MIME Content-type Internet Accounting (acct) Charter Chair(s): Cyndi Mills Gregory Ruth Network Management Area Director(s) Marshall Rose Mailing lists: General Discussion:accounting-wg@wugate.wustl.edu To Subscribe: accounting-wg-request@wugate.wustl.edu Archive: Description of Working Group: The Internet Accounting Working Group has the goal of producing standards for the generation of accounting data within the Internet that can be used to support a wide range of management and cost allocation policies. The introduction of a common set of tools and interpretations should ease the implementation of organizational policies for Internet components and make them more equitable in a multi-vendor environment. In the following accounting model, this Working Group is primarily concerned with defining standards for the Meter function and recommending protocols for the Collector function. Individual accounting applications (billing applications) and organizational policies will not be addressed, although examples should be provided. Meter $<$--$>$ Collector $<$--$>$ Application $<$--$>$ Policy First, examine a wide range of existing and hypothetical policies to understand what set of information is required to satisfy usage reporting requirements. Next, evaluate existing mechanisms to generate this information and define the specifications of each accounting parameter to be generated. Determine the requirements for local storage and how parameters may be aggregated. Recommend a data collection protocol and internal formats for processing by accounting applications. This will result in an Internet-Draft suitable for experimental verification and implementation. In parallel with the definition of the draft standard, develop a suite of test scenarios to verify the model. Identify candidates for prototyping and implementation. \newpage Internet Drafts: No Current Internet drafts. IP over AppleTalk (appleip) Charter Chair(s): John Veizades Internet Area Director(s) Stev Knowles David Piscitello Mailing lists: General Discussion:apple-ip@apple.com To Subscribe: apple-ip-request@apple.com Archive: Description of Working Group: The Macintosh Working Group is chartered to facilitate the connection of Apple Macintoshes to IP internets and to address the issues of distributing AppleTalk services in an IP internet. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 91 Nov 92 A Method for the Transmission of Internet Packets Over AppleTalk Networks [MacIP] Dec 92 New AppleTalk Management Information Base II IP over Asynchronous Transfer Mode (atm) Charter Chair(s): Robert Hinden Internet Area Director(s) Stev Knowles David Piscitello Mailing lists: General Discussion:atm@sun.com To Subscribe: atm-request@sun.com Archive: Send message to atm-request@sun.com Description of Working Group: The IP over ATM Working Group will focus on the issues involved in running internetworking protocols over Asynchronous Transfer Mode (ATM) networks. The final goal for the Working Group is to produce standards for the TCP/IP protocol suite and recommendations which could be used by other internetworking protocol standards (e.g., ISO CLNP and IEEE 802.2 Bridging). The Working Group will initially develop experimental protocols for encapsulation, multicasting, addressing, address resolution, call set up, and network management to allow the operation of internetwork protocols over an ATM network. The Working Group may later submit these protocols for standardization. The Working Group will not develop physical layer standards for ATM. These are well covered in other standard groups and do not need to be addressed in this Group. The Working Group will develop models of ATM internetworking architectures. This will be used to guide the development of specific IP over ATM protocols. The Working Group will also develop and maintain a list of technical unknowns that relate to internetworking over ATM. These will be used to direct future work of the Working Group or be submitted to other standard or research groups as appropriate. The Working Group will coordinate its work with other relevant standards bodies (e.g., ANSI T1S1.5) to insure that it does not duplicate their work and that its work meshes well with other activities in this area. The Working Group will select among ATM protocol options (e.g., selection of an adaptation layer protocol) and make recommendations to the ATM standards bodies regarding the requirements for internetworking over ATM where the current ATM standards do not meet the needs of internetworking. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jun 92 Mar 93 Multiprotocol Interconnect over ATM Adaptation Layer 5 Mar 93 New Partial Address Resolution in ATM Networks Mar 93 New IP over ATM : architecture, address translation, and call control Mar 93 New NBMA Address Resolution Protocol (NBMA ARP) Audio/Video Transport (avt) Charter Chair(s): Stephen Casner Transport Area Director(s) Allison Mankin Mailing lists: General Discussion:rem-conf@es.net To Subscribe: rem-conf-request@es.net Archive: nic.es.net:~/ietf/rem-conf/av-transport-archive Description of Working Group: The Audio/Video Transport Working Group was formed to specify experimental protocols for real-time transmission of audio and video over UDP and IP multicast. The focus of this Group is near-term and its purpose is to integrate and coordinate the current AV transport efforts of existing research activities. No standards-track protocols are expected to be produced because UDP transmission of audio and video is only sufficient for small-scale experiments over fast portions of the Internet. However, the transport protocols produced by this Working Group should be useful on a larger scale in the future in conjunction with additional protocols to access network-level resource management mechanisms. Those mechanisms, research efforts now, will provide low-delay service and guard against unfair consumption of bandwidth by audio/video traffic. Similarly, initial experiments can work without any connection establishment procedure so long as a priori agreements on port numbers and coding types have been made. To go beyond that, we will need to address simple control protocols as well. Since IP multicast traffic may be received by anyone, the control protocols must handle authentication and key exchange so that the audio/video data can be encrypted. More sophisticated connection management is also the subject of current research. It is expected that standards-track protocols integrating transport, resource management, and connection management will be the result of later working group efforts. The AVT Working Group may design independent protocols specific to each medium, or a common, lightweight, real-time transport protocol may be extracted. Sequencing of packets and synchronization among streams are important functions, so one issue is the form of timestamps and/or sequence numbers to be used. The Working Group will not focus on compression or coding algorithms which are domain of higher layers. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 92 New Issues in Designing a Transport Protocol for Audio and Video Conferences and other Multiparticipant Real-Time Applications Dec 92 New A Transport Protocol for Real-Time Applications Dec 92 New Media Encodings Dec 92 New Sample Profile for the Use of RTP for Audio and Video Conferences with Minimal Control Mar 93 New Packetization of H.261 video streams Border Gateway Protocol (bgp) Charter Chair(s): Yakov Rekhter Routing Area Director(s) Robert Hinden Mailing lists: General Discussion:iwg@rice.edu To Subscribe: iwg-request@rice.edu Archive: Description of Working Group: Develop the BGP protocol and BGP technical usage within the Internet, continuing the current work of the Interconnectivity Working Group in this regard. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Aug 91 Oct 92 IP Multicast Communications Using BGP May 92 Dec 92 A Border Gateway Protocol 4 (BGP-4) Sep 92 Dec 92 Definitions of Managed Objects for the Border Gateway Protocol (Version 4) Sep 92 Mar 93 BGP4/IDRP for IP---OSPF Interaction Sep 92 Oct 92 Application of the Border Gateway Protocol in the Internet BGP Deployment and Application (bgpdepl) Charter Chair(s): Jessica Yu Operational Requirements Area Director(s) Scott Bradner Bernhard Stockman Mailing lists: General Discussion:bgpd@merit.edu To Subscribe: bgpd-request@merit.edu Archive: merit.edu:~/pub/bgpd-archive Description of Working Group: The major purpose of this Group is to coordinate BGP deployment and application in the current Internet. It intends to create a forum for BGP users to share BGP deployment experiences and also provide a channel for users to communicate with router vendors who implemented or who are implementing BGP. It also intends to discuss BGP policy application and coordinate policy implementation in the current internet routing environment which includes defining the usage of policy, defining a mechanism to share policy information, etc. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 93 New Notes of BGP-4/CIDR Coordination Meeting of 11 March 93 Mar 93 New Aggregation Support in the NSFNET Policy Routing Database Benchmarking Methodology (bmwg) Charter Chair(s): Scott Bradner Operational Requirements Area Director(s) Scott Bradner Bernhard Stockman Mailing lists: General Discussion:bmwg@harvard.edu To Subscribe: bmwg-request@harvard.edu Archive: Description of Working Group: The major goal of the Benchmarking Methodology Working Group is to make a series of recommendations concerning the measurement of the performance characteristics of different classes of network equipment and software services. Each recommendation will describe the class of equipment or service, discuss the performance characteristics that are pertinent to that class, specify a suite of performance benchmarks that test the described characteristics, as well as specify the requirements for common reporting of benchmark results. Classes of network equipment can be broken down into two broad categories. The first deals with stand-alone network devices such as routers, bridges, repeaters, and LAN wiring concentrators. The second category includes host dependent equipment and services, such as network interfaces or TCP/IP implementations. Once benchmarking methodologies for stand-alone devices have matured sufficiently, the Group plans to focus on methodologies for testing system-wide performance, including issues such as the responsiveness of routing algorithms to topology changes. Internet Drafts: No Current Internet drafts. Bridge MIB (bridge) Charter Chair(s): Fred Baker Network Management Area Director(s) Marshall Rose Mailing lists: General Discussion:bridge-mib@decwrl.dec.com To Subscribe: bridge-mib-request@decwrl.dec.com Archive: Description of Working Group: The Bridge MIB Working Group is chartered to define a set of managed objects that instrument devices that conform to the IEEE 802.1 standard for MAC-layer bridges. This set of objects should be largely compliant with (and even draw from) IEEE 802.1(b), although there is no requirement that any specific object be present or absent. The MIB object definitions produced will be for use by SNMP and will be consistent with other SNMP objects, standards, and conventions. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 92 Oct 92 Definitions of Managed Objects for Bridges Common Authentication Technology (cat) Charter Chair(s): John Linn Security Area Director(s) Stephen Crocker Mailing lists: General Discussion:cat-ietf@mit.edu To Subscribe: cat-ietf-request@mit.edu Archive: bitsy.mit.edu:~/cat-ietf/archive Description of Working Group: The goal of the Common Authentication Technology Working Group is to provide strong authentication to a variety of protocol callers in a manner which insulates those callers from the specifics of underlying security mechanisms. By separating security implementation tasks from the tasks of integrating security data elements into caller protocols, those tasks can be partitioned and performed separately by implementors with different areas of expertise. This provides leverage for the IETF community's security-oriented resources, and allows protocol implementors to focus on the functions their protocols are designed to provide rather than on characteristics of security mechanisms. CAT seeks to encourage uniformity and modularity in security approaches, supporting the use of common techniques and accommodating evolution of underlying technologies. In support of these goals, the Working Group will pursue several interrelated tasks. We will work towards agreement on a common service interface allowing callers to invoke security services, and towards agreement on a common authentication token format, incorporating means to identify the mechanism type in conjunction with which authentication data elements should be interpreted. The CAT Working Group will also work towards agreements on suitable underlying mechanisms to implement security functions; two candidate architectures (Kerberos V5, based on secret-key technology and contributed by MIT, and X.509-based public-key Distributed Authentication Services being prepared for contribution by DEC) are under current consideration. The CAT Working Group will consult with other IETF working groups responsible for candidate caller protocols, pursuing and supporting design refinements as appropriate. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jun 91 Nov 92 Generic Security Service Application Program Interface Jul 91 Sep 92 The Kerberos Network Authentication Service (V5) Jul 91 Mar 93 Generic Security Service API : C-bindings Nov 91 Dec 92 Distributed Authentication Security Service Apr 93 New FTP Security Extensions Chassis MIB (chassis) Charter Chair(s): Bob Stewart Jeffrey Case Network Management Area Director(s) Marshall Rose Mailing lists: General Discussion:chassismib@cs.utk.edu To Subscribe: chassismib-request@cs.utk.edu Archive: Description of Working Group: This Working Group will produce a document describing MIB objects for use in a ``chassis'' --- which is a collection of traditionally discrete network devices packaged in a single cabinet and power supply. A chassis may comprise, for example, combinations of layer 1 repeater elements, MAC layer bridges, or internetwork layer routers. The Working Group is chartered to produce up to three distinct documents that define extensions to the SNMP MIB: (1) The Working Group is chartered to define MIB objects that represent the mapping of the logical functions of traditional network devices onto particular, physical hardware resources within the chassis. These MIB definitions will not address any aspects of the network functions comprised by a chassis box that are shared with an analogous collection of discrete network devices. (2) The Working Group is chartered, at its option, to define MIB objects that instrument the operational state of a power supply element in a chassis. (3) The Working Group is chartered, at its option, to define MIB objects that represent aggregated information about collections of network devices (e.g., aggregate information about devices attached to a particular LAN), provided that this MIB specification is not specific to chassis implementations of such networks and is also readily implementable for analogous collections of discrete network devices. The MIB object definitions produced will be for use by SNMP and will be consistent with existing SNMP standards and framework. Although the Working Group may choose to solicit input or expertise from other relevant standards bodies, no extant standards efforts or authorities are known with which alignment of this work is required. Because the structure of chassis implementations varies widely, the Working Group shall take special care that its definitions reflect a generic and consistent architectural model of chassis management rather than the structure of particular chassis implementations. Should the Working Group elect to define objects representing aggregated information about collections of network devices, those efforts will not compromise the operational robustness of the SNMP that depends on its realization of management system function as closely as possible to centers of responsible authority. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jan 93 New Definitions of Managed Objects for a Chassis Containing Multiple Logical Network Devices Commercial Internet Protocol Security Option (cipso) Charter Chair(s): Ron Sharp Security Area Director(s) Stephen Crocker Mailing lists: General Discussion:cipso@wdl1.wdl.loral.com To Subscribe: cipso-request@wdl1.wdl.loral.com Archive: archive-server@wdl1.wdl.loral.com Description of Working Group: The Commercial Internet Protocol Security Option Working Group is chartered to define an IP security option that can be used to pass security information within and between security domains. This new security option will be modular in design to provide developers with a single software environment which can support multiple security domains. The CIPSO protocol will support a large number of security domains. New security domains will be registered with the Internet Assigned Numbers Authority (IANA) and will be available with minimal difficulty to all parties. There is currently in progress another IP security option referred to as IPSO (RFC 1108). IPSO is designed to support the security labels used by the U.S. Department of Defense. CIPSO will be designed to provide labeling for the commercial, U.S. civilian and non-U.S. communities. The Trusted Systems Interoperability Group (TSIG) has developed a document which defines a structure for the proposed CIPSO option. The Working Group will use this document as a foundation for developing an IETF CIPSO specification. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Dec 91 Aug 92 COMMERCIAL IP SECURITY OPTION (CIPSO 2.2) Mar 93 New COMMON IP SECURITY OPTION Distributed File Systems (dfs) Charter Chair(s): Peter Honeyman Service Applications Area Director(s) Dave Crocker Mailing lists: General Discussion:dfs-wg@citi.umich.edu To Subscribe: dfs-wg-request@citi.umich.edu Archive: Description of Working Group: Trans- and inter-continental distributed file systems are upon us. The consequences to the Internet of distributed file system protocol design and implementation decisions are sufficiently dire that we need to investigate whether the protocols being deployed are really suitable for use on the Internet. There's some evidence that the opposite is true, e.g., some distributed file systems protocols don't checksum their data, don't use reasonable MTUs, don't offer credible authentication or authorization services, don't attempt to avoid congestion, etc. Accordingly, a Working Group on DFS has been formed by the IETF. The Working Group will attempt to define guidelines for ways that distributed file systems should make use of the network, and to consider whether any existing distributed file systems are appropriate candidates for Internet standardization. The Working Group will also take a look at the various file system protocols to see whether they make data more vulnerable. This is a problem that is especially severe for Internet users, and a place where the IETF may wish to exert some influence, both on vendor offerings and user expectations. Internet Drafts: No Current Internet drafts. Dynamic Host Configuration (dhc) Charter Chair(s): Ralph Droms Internet Area Director(s) Stev Knowles David Piscitello Mailing lists: General Discussion:host-conf@sol.bucknell.edu To Subscribe: host-conf-request@sol.bucknell.edu Archive: sol.bucknell.edu:~/dhcwg Description of Working Group: The purpose of this Working Group is the investigation of network configuration and reconfiguration management. We will determine those configuration functions that can be automated, such as Internet address assignment, gateway discovery and resource location, and those which cannot be automated (i.e., those that must be managed by network administrators). Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ May 91 Sep 92 Clarifications and Extensions for the Bootstrap Protocol Jul 91 Jan 93 Dynamic Host Configuration Protocol Jun 92 Jan 93 DHCP Options and BOOTP Vendor Extensions Jun 92 Jan 93 Interoperation Between DHCP and BOOTP Domain Name System (dns) Charter Chair(s): Rob Austein Service Applications Area Director(s) Dave Crocker Mailing lists: General Discussion:namedroppers@nic.ddn.mil To Subscribe: namedroppers-request@nic.ddn.mil Archive: nicfs.nic.ddn.mil:~/namedroppers/*.Z Description of Working Group: The DNS Working Group is concerned with the design, operation, and evolution of the Domain Name System within the Internet. As the Internet continues to grow, we expect to serve as a focal point for work on scaling problems within the current framework, work on protocol evolution as new mechanisms become necessary, and documentation of current practice for DNS implementors and administrators. We are also responsible for oversight of DNS activities by other groups within the IETF to the extent that we review the impact such work will have on the DNS and make recomendations to the working groups and IESG as necessary. Since some of these are ongoing tasks, we do not expect the working group to disband anytime soon. Several issues are of particular concern at this time: Scaling. The DNS is the victim of its own success. The global DNS namespace has grown to the point where administering the top levels of the tree is nearly as much work as the old NIC host table used to be. We need to work on ways to distribute the load. Some of the solutions are likely to be technical, some political or economic; we still treat the top-level DNS service the way we did when DARPA was footing the bill, and the funding for that service is in the process of going away. Security. The DNS is a zero-security system; it is not even as strong as the IP layer above which it operates. As a result, accidental spoofing (cache pollution) is an all-too-frequent occurance. We need to make the DNS more robust against accidental corruption, and must provide at least an optional authentication mechanism for that portion of the community that wants one. At the same time, we must not cripple the existing system by drasticly increasing its bandwidth consumption or by mandating use of cryptographic techniques that would preclude worldwide distribution of DNS software. The global DNS database is exactly that, an existing world-wide database representing hosts on six continents and (at least) forty-five countries. A solution that does not take this into account is not acceptable. Management. We have a draft document describing MIB extensions to manage the DNS. We also need to specify a standard way to dynamically create and destroy DNS records; SNMP may be an appropriate tool for this task, but we haven't yet specified enough of the details to know for certain. We need to examine the impact that a dynamic update mechanism will have on the DNS, with particular attention to security and scaling issues. IPv7/Routing. As the fur starts flying in the battle between the IPv7 proponants and the new-routing-architecture proponants, we expect that groups on both sides will need some amount of support from the DNS. Such support is likely to be minimal and straightforward, but these proposals are likely to need "rush service" for whatever support they require. So the working group needs to monitor these activities, stay involved, and generally do what it can to make sure that DNS support is not a bottleneck. We also need to examine the impact that any proposed IPv7 system would have on the DNS, since the DNS database and protocols have special provision for IP addresses. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 92 Nov 92 DNS MIB Extensions Mar 93 New DNS Support for IDPR Apr 93 New Using the Domain Name System To Store Arbitrary String Attributes FDDI MIB (fddimib) Charter Chair(s): Jeffrey Case Network Management Area Director(s) Marshall Rose Mailing lists: General Discussion:fddi-mib@CS.UTK.EDU To Subscribe: fddi-mib-request@CS.UTK.EDU Archive: Description of Working Group: The FDDI MIB Working Group is chartered to define a MIB for FDDI devices that is consistent with relevant FDDI specifications produced by ANSI. All definitions produced by this Working Group will be consistent with the SNMP network management framework and other internet-standard MIBs for SNMP. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 93 Mar 93 FDDI Management Information Base Host Resources MIB (hostmib) Charter Chair(s): Steven Waldbusser Network Management Area Director(s) Marshall Rose Mailing lists: General Discussion:hostmib@andrew.cmu.edu To Subscribe: hostmib-request@andrew.cmu.edu Archive: Description of Working Group: The Host Resources MIB Working Group is chartered to produce exactly one document that defines SNMP MIB objects that instrument characteristics common to all internet hosts. The goal of this work is to address the urgent operational need in the internet community for management of host systems. Owing to this urgency, the Working Group will focus exclusively on the alignment of existing MIB technology in order to achieve common solutions in a timely manner. For purposes of this effort, the term ``internet host'' is construed to mean any computer that communicates with other similar computers attached to the internet and that is directly used by one or more human beings. Although the work of the Group does not necessarily apply to devices whose primary function is communications services (e.g., terminal servers, routers, bridges, monitoring equipment), such relevance is not explicitly precluded. The single MIB produced shall instrument attributes common to all internet hosts including, for example, both personal computers and systems that run variants of Unix. The methodology of this Working Group is to focus entirely on the alignment of existing, enterprise-specific MIBs for SNMP that are relevant to its task. The Group will work towards its goal by distillation and generalization of these existing MIBs into a single, common MIB definition. Owing to the urgent operational need for managing host systems, this effort will not be comprehensive in scope. Rather, the MIB produced by this Group will be confined to critical information about hardware and software configuration, processor and memory use, and data storage capacities, backup, and use. Owing to the lack of a well-understood and accepted architecture, the Working Group will not address in any way, mechanisms that could be used to monitor or control the use of licensed software products. All definitions produced by the Group will be consistent with the SNMP network management framework and all other internet-standard MIBs for SNMP. Wherever possible, the definitions produced will make use of or align with relevant work in progress with chartered working groups of the IETF. Also, wherever possible, the Working Group will take into consideration pre-existing, stable work produced by other, accredited standards bodies. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 92 New Host Resources MIB IEEE 802.3 Hub MIB (hubmib) Charter Chair(s): Keith McCloghrie Donna McMaster Network Management Area Director(s) Marshall Rose Mailing lists: General Discussion:hubmib@synoptics.com To Subscribe: hubmib-request@synoptics.com Archive: sweetwater.synoptics.com"~/pub/hubmib Description of Working Group: This Working Group will produce a document describing MIB objects for use in managing Ethernet-like hubs. A hub is defined as a multiport repeater that conforms to Section 9, ``Repeater Unit for 10 Mb/s Baseband Networks'' in the IEEE 802.3/ISO 8802-3 CSMA/CD standard (2nd edition, Sept. 1990). These Hub MIB objects may be used to manage non-standard repeater-like devices, but defining objects to describe vendor-specific properties of non-standard repeater-like devices are outside the scope of this Working Group. The MIB object definitions produced will be for use by SNMP and will be consistent with other SNMP objects, conventions, and definitions. In order to minimize the instrumentation burden on managed agents, the MIB definitions produced by the Working Group will, wherever feasible, be semantically consistent with the managed objects defined in the IEEE draft standard P802.3K, ``Layer Management for Hub Devices.'' The Working Group will base its work on the draft that is the output of the July 1991 IEEE 802 plenary meeting. The Working Group will take special cognizance of Appendix B of that specification that sketches a possible realization of the relevant managed objects in the SNMP idiom. Consistent with the IETF policy regarding the treatment of MIB definitions produced by other standards bodies, the Working Group may choose to consider only a subset of those objects in the IEEE specification and is under no obligation to consider (even for ``Optional'' status) all objects defined in the IEEE specification. Moreover, when justified by special operational needs of the community, the Working Group may choose to define additional MIB objects that are not present in the IEEE specification. Although the definitions produced by the Working Group should be architecturally consistent with MIB-II and related MIBs wherever possible, the Charter of the Working Group does not extend to perturbing the conceptual models implicit in MIB-II or related MIBs in order to accommodate 802.3 Hubs. In particular, to the extent that the notion of a ``port'' in an 802.3 Hub is not consistent with the notion of a network ``interface'' as articulated in MIB-II, it shall be modelled independently by objects defined in the Working Group. Because the structure of 802.3 Hub implementations varies widely, the Working Group shall take special care that its definitions reflect a generic and consistent architectural model of Hub management rather than the structure of particular Hub implementations. The IEEE Hub Management draft allows an implementor to separate the ports in a hub into groups, if desired (i.e., a vendor might choose to represent field-replaceable unites as groups of ports so that the port numbering would match a modular hardware implementation.) Because the Working Group Charter does not extend to consideration of fault-tolerant, highly-available systems in general, its treatment of these groups of ports in an 802.3 Hub (if any) shall be specific to Hub management and without impact upon other portions of the MIB. The Working Group is further chartered at its discretion to define an SNMP MIB for management of IEEE 802.3 Medium Access Units (MAUs). An 802.3 Medium Attachment Unit (MAU) attaches a repeater port or Ethernet-like interface to the local network medium. The scope of this work may include several types of MAU units: 10BASE5 (thick coax), 10BASE2 (thin coax), 10BASE-T (twisted pair), FOIRL and 10BASE-F (fiber optic). Managed objects defined as part of the MAU MIB task may, for example, represent such information as MAU type, link status, and jabbering indications. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 93 Mar 93 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) Internet Anonymous FTP Archives (iafa) Charter Chair(s): Peter Deutsch Alan Emtage User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:iafa@cc.mcgill.ca To Subscribe: iafa-request@cc.mcgill.ca Archive: archive.cc.mcgill.ca:~/pub/iafa-archive Description of Working Group: The Internet Anonymous FTP Archives Working Group is chartered to define a set of recommended standard procedures for the access and administration of anonymous ftp archive sites on the Internet. Such a set of procedures will provide a framework for: (a) Allowing the inexperienced Internet user the ability to more easily navigate the hundreds of publically accessible archive sites. (b) Allowing users and network-based tools to retrieve specific site information such as access policies, contact information, possible areas of information specialization, archived package descriptions, etc., in a standardized manner. Particular emphasis will be placed on the possible impact of these procedures on the FTP site administrators. Attention will be paid to the impact of newer archive indexing and access tools on the operation of such archive sites. A set of suggestions will be offered to allow archive site administrators to better integrate their offerings with such tools as they are developed. The security of the anonymous FTP site configuration will also be considered to be an integral part of this document. It is expected that remote management of the archives will be adequately handled by existing network management procedures. Internet Drafts: No Current Internet drafts. Inter-Domain Policy Routing (idpr) Charter Chair(s): Martha Steenstrup Routing Area Director(s) Robert Hinden Mailing lists: General Discussion:idpr-wg@bbn.com To Subscribe: idpr-wg-request@bbn.com Archive: Description of Working Group: The Inter Domain Policy Routing Working Group is chartered to develop an architecture and set of protocols for policy routing among large numbers of arbitrarily interconnected administrative domains. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Feb 90 Jun 92 An Architecture for Inter-Domain Policy Routing Mar 91 Jun 92 Inter-Domain Policy Routing Protocol Specification: Version 1 Jul 91 Mar 93 Definitions of Managed Objects for the Inter-Domain Policy Routing Protocol (Version 1) Apr 92 New IDPR as a Proposed Standard Integrated Directory Services (ids) Charter Chair(s): Chris Weider Tim Howes User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:ids@merit.edu To Subscribe: ids-request@merit.edu Archive: merit.edu:~/pub/ids-archive Description of Working Group: The Integrated Directory Services Working Group (IDS) is chartered to facilitate the integration and interoperability of current and future directory services into a unified directory service. This work will unite directory services based on a heterogeneous set of directory services protocols (X.500, WHOIS++, etc.). In addition to specifying technical requirements for the integration, the IDS Group will also contribute to the administrative and maintenance issues of directory service offerings by publishing guidelines on directory data integrity, maintenance, security, and privacy and legal issues for users and administrators of directories. IDS will also assume responsibility for the completion of the outstanding Directory Information Services Infrastructure (DISI) Internet-Drafts, which are all specific to the X.500 protocol, and for the maintenance of FYI 11, ``A catalog of available X.500 implementations''. IDS will need to liase with the groups working on development and deployment of the various directory service protocols. The IDS Working Group is a combined effort of the Applications Area and the User Services Area of the IETF. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 92 Mar 93 A Survey of Advanced Usages of X.500 Integration of Internet Information Resources (iiir) Charter Chair(s): Chris Weider User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:iiir@merit.edu To Subscribe: iiir-request@merit.edu Archive: merit.edu:~/pub/iiir-archive Description of Working Group: The Integration of Internet Information Resources Working Group (IIIR) is chartered to facilitate interoperability between Internet Information Services, and to develop, specify, and align protocols designed to integrate the plethora of Internet information services (WAIS, ARCHIE, Prospero, etc.) into a single ``virtually unified information service'' (VUIS). Such protocols would include (but are not limited to) update protocols for distributed servers, a `query routing protocol' to pass queries between existing services, protocols for gateways between existing and future services, and standard exchange formats (perhaps based on Z39.50) for cross-listing specific information. Also, where necessary, IIIR will create technical documentation for protocols used for information services in the Internet. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 93 New Resource Transponders Mar 93 New A Vision of an Integrated Internet Information Service IP Address Encapsulation (ipae) Charter Chair(s): Dave Crocker Internet Area Director(s) Stev Knowles David Piscitello Mailing lists: General Discussion:ip-encaps@sunroof.eng.sun.com To Subscribe: ip-encaps-request@sunroof.eng.sun.com Archive: parcftp.xerox.com:~/pub/ip-encaps/ Description of Working Group: The IPAE Working Group seeks to develop a capability for extending IP to support larger addresses while minimizing impact on the installed base of IP users. An enhancement to the current system is mandatory due to the limitations of the current 32 bit IP addresses. IPAE seeks to upgrade the current system, rather than to replace the Internet Protocol. The approach taken will be to sandwhich a small addressing layer, above IP but below TCP or UDP, with the new layer having its own IP Protocol-ID. This special layer will thereby encapsulate new, larger, globally-unique addresses for source and destination, as well as any other fields of information that are considered essential. The specificaton effort will attend to issues of transition and coexistance, among unmodified ``IP'' hosts and hosts which support ``IPAE'' hosts The IPAE approach will develop a framework to organize the Internet into areas called ``IP Addressing Commonwealths'' within which 32-bit IP addresses are unique and are part of a larger, globally-unique Internet addressing scheme. It is a goal of this effort to avoid requiring any router within a Commonwealth to be modified, but any host wishing full Internet connectivity will need to support IPAE eventually. Further, any system wishing to support full IPAE addresses will need to be modified, including network management software. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 92 New IPv7 Criteria Analysis for IP Address Encapsulation (IPAE) and the Simple Internet Protocol (SIP) Nov 92 New IP Address Encapsulation (IPAE): A Mechanism for Introducing a New IP OSI IDRP for IP over IP (ipidrp) Charter Chair(s): Sue Hares Routing Area Director(s) Robert Hinden Mailing lists: General Discussion:idrp-for-ip@merit.edu To Subscribe: idrp-for-ip-request@merit.edu Archive: merit.edu:~/pub/archive/idrp Description of Working Group: The IDRP for IP over IP Working Group is chartered to standardize and promote the use of IDRP (ISO Inter-Domain Routing Protocol) as a scalable inter- autonomous system routing protocol capable of supporting Policy Based Routing for TCP/IP internets. The objective is to take IDRP, as it is defined by ISO standards, and to define backward compatible extensions and/or network adaptation layers to enable this protocol to be used in the TCP/IP internets. If any ISO standardization efforts overlap this area of work, it is intended that the ISO work will supersede the standards proposed by this Group. 1) IDRP for IP over IP document (standards track) This document contains the appropriate adaptations of the IDRP protocol definition that enables it to be used as a protocol for exchange of ``inter-autonomous system information'' among routers to support forwarding of IP packets across multiple autonomous systems. 2) IDRP MIB document (standards track) This document contains the MIB Definitions for IDRP. These MIB Definitions are done in two parts; IDRP General MIB, and IDRP for IP MIB. An appendix is planned; IDRP For IP GDMO 3) IDRP - OSPF Interactions (standards track) This document will specify the interactions between IDRP and OSPF. This document will be based on a combination of BGP-OSPF interactions document and IDRP - ISIS interaction document. 4) IDRP for IP Usage document (standards track) Most of the IDRP for IP Usage will reference the CIDR (Supernetting document) Internet Draft. Any additional terms or protocol definitions needed for IDRP for IP will also be specified here. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 93 New IDRP for SIP IP over Large Public Data Networks (iplpdn) Charter Chair(s): George Clapp Internet Area Director(s) Stev Knowles David Piscitello Mailing lists: General Discussion:iplpdn@cnri.reston.va.us To Subscribe: iplpdn-request@cnri.reston.va.us Archive: ietf.cnri.reston.va.us:~/ietf-mail-archive/iplpdn/* Description of Working Group: The IP over Large Public Data Networks Working Group will specify the operation of the TCP/IP protocol suite over Public Data Networks (PDNs) such as SMDS, ISDN, X.25 PDNs, and Frame Relay. The Working Group will develop and define algorithms for the resolution of IP addresses and for the routing of IP datagrams over large, potentially global, public data networks. The IP over SMDS Working Group has defined the operation of the Internet protocols when SMDS is used to support relatively small virtual private networks, or Logical IP Subnets (LISs). Issues arising from public and global connectivity were delegated to the IPLPDN Working Group. The IPLPDN Working Group will also continue the work of the Private Data Network Routing Working Group (PDNROUT) on X.25 PDNs. This work will be extended to include call management and the use of the ISDN B channels for the transport of IP datagrams. Address resolution and routing over Frame Relay will also be discussed. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jun 92 Jan 93 Shortcut Routing: Discovery and Routing over Large Public Data Networks Jan 93 Mar 93 Multiprotocol Interconnect over Frame Relay Networks Feb 93 New The Transmission of Multi-protocol Datagrams over Circuit-mode ISDN Feb 93 New Parameter Negotiation for the Multiprotocol Interconnect Mar 93 New Management Information Base for Frame Relay DTEs ISIS for IP Internets (isis) Charter Chair(s): Ross Callon Chris Gunner Routing Area Director(s) Robert Hinden Mailing lists: General Discussion:isis@merit.edu To Subscribe: isis-request@merit.edu Archive: Description of Working Group: The IETF ISIS Working Group will develop additions to the existing OSI IS-IS Routing Protocol to support IP environments and dual (OSI and IP) environments. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 91 Mar 93 Integrated IS-IS Management Information Base Jan 93 New Use of OSI IS-IS for Routing in TCP/IP and Multi-Protocol Environments Internet School Networking (isn) Charter Chair(s): John Clement Arthur St. George Connie Stout User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:isn-wg@unmvma.unm.edu To Subscribe: listserv@unmvma.unm.edu In Body: subscribe isn-wg Archive: Description of Working Group: The Internet School Networking Working Group is chartered to facilitate the connection of the United States' K-12 (Kindergarten-12th Grade) schools, public and private, to the Internet, and school networking in general. It is critically important that national networking for K-12 education proceed along established lines of protocol, using existing network structures. The Working Group's first priority will be to establish guidelines for specialized user interfaces. K-12 networking will also require other support services, such as directories, online and hotline help, specialized training programs and collaborative projects with instructional and curriculum groups, disciplinary groups and postsecondary institutions. While the initial focus is school networking in the U.S., the Working Group will coordinate its efforts with similar activities in other countries and regions of the world. Internet Drafts: No Current Internet drafts. MHS-DS (mhsds) Charter Chair(s): Kevin Jordan Harald Alvestrand Service Applications Area Director(s) Dave Crocker Mailing lists: General Discussion:mhs-ds@mercury.udev.cdc.com To Subscribe: mhs-ds-request@mercury.udev.cdc.com Archive: mercury.udev.cdc.com:~/pub/archives/mhs-ds-archive Description of Working Group: The MHS-DS Working Group works on issues relating to Message Handling Services use of Directory Services. The Message Handling Services are primarily X.400, but issues relating to RFC822 use of Directory and Directory support for RFC822 and X.400 interworking are in the scope of the Group. Directory and Directory Services refer to the services based upon the CCITT X.500 recommendations and additional ISO standards, stable implementation agreements, and RFCs, as specified by the OSI-DS Working Group. The major aims of the MHS-DS working group are: 1. Define a set of specifications to enable effective, large-scale deployment of X.400. 2. Study issues associated with supporting X.400 communities which lack access to X.500 Directory, and define requirements for tools which: a) extract information from the X.500 Directory for use by non-X.500 applications, b) upload information into the X.500 Directory. 3. Coordinate a pilot project which deploys MHS information into the X.500 Directory and uses it to facilitate mail routing and address mapping. The results of this pilot will be documented, and experience gained from the project will be fed back into the Internet specifications created by the working group. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Apr 92 Nov 92 Use of the Directory to support routing for RFC 822 and related protocols Apr 92 Nov 92 A simple profile for MHS use of Directory Apr 92 Nov 92 Representing Tables and Subtrees in the Directory Apr 92 Nov 92 Representing the O/R Address hierarchy in the Directory Information Tree Apr 92 Nov 92 Use of the Directory to support mapping between X.400 and RFC 822 Addresses Apr 92 Nov 92 MHS use of the Directory to support distribution lists Apr 92 Nov 92 MHS use of Directory to support MHS Routing Nov 92 New MHS use of Directory to support MHS Content Conversion MIME-MHS Interworking (mimemhs) Charter Chair(s): Steve Thompson Applications Area Director(s) Brewster Kahle Erik Huizer Mailing lists: General Discussion:mime-mhs@surfnet.nl To Subscribe: mime-mhs-request@surfnet.nl Archive: Description of Working Group: MIME, (Multipurpose Internet Mail Extensions) is currently a Proposed Standard. MIME redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. With the introduction of MIME as a Proposed Standard it is now possible to define mappings between RFC-822 content-types and X.400 body parts. The MIME-MHS Interworking Working Group is chartered to develop these mappings, providing an emphasis on both interworking between Internet and MHS mail environments and also on tunneling through these environments. These mappings will be made in the context of an RFC-1148bis environment. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jul 92 Mar 93 Mapping between X.400 and RFC-822 Message Bodies Jul 92 Nov 92 Equivalences between 1988 X.400 and RFC-822 Message Bodies Sep 92 Feb 93 HARPOON: Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages Multicast Extensions to OSPF (mospf) Charter Chair(s): Steve Deering Routing Area Director(s) Robert Hinden Mailing lists: General Discussion:mospf@comet.cit.cornell.edu To Subscribe: mospf-request@comet.cit.cornell.edu Archive: Description of Working Group: This Working Group will extend the OSPF routing protocol so that it will be able to efficiently route IP multicast packets. This will produce a new (multicast) version of the OSPF protocol, which will be as compatible as possible with the present version (packet formats and most of the algorithms will hopefully remain unaltered). Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jul 91 Mar 93 Multicast Extensions to OSPF Nov 92 Jan 93 IP Multicast over Token-Ring Local Area Networks Network Access Server Requirements (nasreq) Charter Chair(s): Allan Rubens John Vollbrecht Security Area Director(s) Stephen Crocker Mailing lists: General Discussion:nas-req@merit.edu To Subscribe: nas-req-request@merit.edu Archive: Description of Working Group: The Network Access Server Requirements Working Group has as its primary goal, to identify functions and services that should be present in IP Network Access Servers (NAS's) and to specify the standards that provide for these functions and services. The term ``Network Access Server'' is used instead of the more conventional term ``Terminal Server'' as it more accurately describes the functions of interest to this Group. A ``Network Access Server'' is a device that provides for the attachment of both traditional ``dumb terminals'' and terminal emulators as well as workstations, PC's or routers utilizing a serial line framing protocol such as PPP or SLIP. A NAS is viewed as a device that sits on the boundary of an IP network, providing serial line points of attachment to the network. A NAS is not necessarily a separate physical entity; for example, a host system supporting serial line attachments is viewed as providing NAS functionality and should abide by NAS requirements. This Group will adopt (or define, if need be) a set of standard protocols to meet the needs of organizations providing network access. The immediate needs to be addressed by the Group are in the areas of authentication, authorization, and accounting (AAA). In general, this Group will select a set of existing standards as requirements for a NAS. If necessary, the Group will identify areas of need where internet standards don't already exist and new standardization efforts may be required. Initially the Group will independently investigate the two cases of character and frame oriented access to the NAS. This investigation will be aimed at determining what work is being done, or needs to be done, in this and other working groups in order to be able to define the set of NAS requirements. While the ultimate goal of this Group is to produce a NAS Requirements document, it may be necessary to define standards as well. This initial investigation will help determine what the goals of this Group need to be. The Group will also work with appropriate Working Groups to define required NAS standards that fall into the areas of these other groups. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 92 New Network Access Server Proposed Requirements Document Network Database (netdata) Charter Chair(s): Daisy Shen Applications Area Director(s) Brewster Kahle Erik Huizer Mailing lists: General Discussion:ietf-ndb@ucdavis.edu To Subscribe: ietf-ndb-request@ucdavis.edu Archive: Description of Working Group: The Network Database Working Group is chartered to define a standard interface among databases on TCP/IP networks. The Working Group will address the issue of database connectivity in a distributed environment which allows authorized users remote access to databases. It will be designed as a client/server model based on TCP/IP as its communication protocol. Several problems must be resolved that are associated with the network database protocol, such as management of multiple threads between clients and servers, management of multiple servers, management of data buffers, data conversions, and security. Additional related problems will be covered as the discussion goes on. Therefore, the description and the schedule can be revised. This Working Group is independent from the SQL access group; however, there may be some overlapping interest. The SQL access group is welcome to join IETF's discussions and share information in both directions. If both groups find that merging two efforts into one will speed up the process, the merge can be done in the future. For now, this Working Group works on issues according to its own schedule and efforts. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jun 91 Feb 93 Network Database Protocol Dec 91 Feb 93 Network Database Implementation Information Internet Draft Networked Information Retrieval (nir) Charter Chair(s): Jill Foster George Brett User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:nir@mailbase.ac.uk To Subscribe: mailbase@mailbase.ac.uk In Body: subscribe nir Archive: mailbase.ac.uk:~/pub/nir Description of Working Group: As the network has grown, along with it there has been an increase in the number of software tools and applications to navigate the network and make use of the many, varied resources which are part of the network. Within the past year and a half we have seen a wide spread adoption of tools such as the ARCHIE servers, the Wide Area Information Servers (WAIS), the Internet Gopher, and the WorldWide Web (WWW). In addition to the acceptance of these tools there are also diverse efforts to enhance and customize these tools to meet the needs of particular network communities. There are many organizations and associations that have recently begun to focus on the proliferating resources and tools for networked information retrieval (NIR). The Networked Information Retrieval Group will be a cooperative effort of three major players in the field of NIR: IETF, RARE, and the Coalition for Networked Information (CNI) specifically tasked to collect and disseminate information about the tools and to discuss and encourage cooperative development of current and future tools. The NIR Working Group intends to increase the useful base of information about networked information retrieval (NIR) tools, their developers, interested organizations, and other activities that relate to the production, dissemination, and support of NIR tools, to produce documentation that will enable user services organizations to provide better support for NIRtools, to develop materials that will assist the support and training of end users and to evolve in the future as necessary to meet and anticipate changes in the field (i.e., NIR tools, protocols, network topology, etc.) Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 93 New A Status Report on Networked Information Retrieval: Tools and Groups Network Information Services Infrastructure (nisi) Charter Chair(s): April Marine Pat Smith User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:nisi@merit.edu To Subscribe: nisi-request@merit.edu Archive: Description of Working Group: The NISI Working Group will explore the requirements for common, shared Internet-wide network information services. The goal is to develop an understanding for what is required to implement an information services ``infrastructure'' for the Internet. The work will begin with existing NIC functions and services and should build upon work already being done within the Internet community. It should address areas such as common information formats, methods of access, user interface, and issues relating to security and privacy of Internet databases. Internet Drafts: No Current Internet drafts. Network Joint Management (njm) Charter Chair(s): Gene Hastings Operational Requirements Area Director(s) Scott Bradner Bernhard Stockman Mailing lists: General Discussion:njm@merit.edu To Subscribe: njm-request@merit.edu Archive: Description of Working Group: There is a need for many different kinds of efforts to deal with operational and front line engineering issues, including helping the disparate organizations work with each other. This is an attempt to solidify some of those topics. This does not make any pretense of being exhaustive. Area of interest: Operational issues and developments of the Internet. Membership: Operations and engineering personnel from national backbone and mid-level networks. Other groups with responsibility for production oriented services such as security oriented groups. Associated Technical groups: Groups which will have an interest in, and input to the Agenda of this Group will include the IAB and its task forces, and groups within FARNET. In particular FARNET has now several technical issues of concern, such as the selection of standard inter-network services for debugging (like maps and standard SNMP communities), and the specification of standard network statistics to be taken (of special concern is the ubiquitous ability to collect those statistics). Meeting Times: Members of the Group will represent organizations with production responsiblities. Most work will be carried on via email or teleconferencing. Internet Drafts: No Current Internet drafts. Network News Transport Protocol (nntp) Charter Chair(s): Eliot Lear Applications Area Director(s) Brewster Kahle Erik Huizer Mailing lists: General Discussion:ietf-nntp@turbo.bio.net To Subscribe: ietf-nntp-request@turbo.bio.net Archive: Description of Working Group: This Group will study and review the issues involved with netnews transport over the Internet. Originally released as an RFC in February of 1986, NNTP is one of the widest implementations of an elective status protocol. As of this writing, the protocol has just passed its fifth birthday, not having been updated once. Over the years several enhancements have been suggested, and several have even been implemented widely. The intent of this Working Group will be to encode the more popular and plausible enhancements into an Internet standard. Included in the initial list of changes to be considered are the following: (1) User level and site designated authentication methods; (2) Binary transfer capability; (3) Minimization of line turnaround; and (4) Stronger article selection capability. It is expected that public domain software will be released concurrently with an RFC, demonstrating the protocol enhancements. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Sep 91 Dec 92 Network News Transfer Protocol Version 2: A Protocol for the Stream-Based Transmission of News Network OSI Operations (noop) Charter Chair(s): Susan Hares Cathy Wittbrodt Operational Requirements Area Director(s) Scott Bradner Bernhard Stockman Mailing lists: General Discussion:noop@merit.edu To Subscribe: noop-request@merit.edu Archive: merit.edu:~/pub/noop-archive Description of Working Group: The Working Group is chartered to work on issues related to the deployment of CLNP in the Internet. The first area of this Group's work has been the learning necessary to start deploying OSI in internet networks. This phase includes planning for OSI deployment by creating routing plans for regional networks and education on using OSI routing protocols. This first area of the Group's work will be on-going as we continue to deploy OSI in the Internet. This step has lead to people deploying OSI for Pilot projects and demonstrations of OSI. The second step of deploying OSI will be the transition of OSI from a pilot service to a production service. During this phase we will work on specifying the network debugging tools and test beds. We will need to track the level of OSI support in the Internet. We will need to provide documentation for new users of OSI on the Internet. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 92 Feb 93 An Echo Function for ISO 8473 Nov 92 Mar 93 Essential Tools for the OSI Internet Mar 93 New Essential Tools for the OSI Internet Network Printing Protocol (npp) Charter Chair(s): Glenn Trewitt Applications Area Director(s) Brewster Kahle Erik Huizer Mailing lists: General Discussion:print-wg@pa.dec.com To Subscribe: print-wg-request@pa.dec.com Archive: Description of Working Group: The Network Printing Working Group has the goal of pursuing those issues which will facilitate the use of printers in an internetworking environment. In pursuit of this goal it is expected that we will present one or more printing protocols to be considered as standards in the Internet community. This Working Group has a number of specific objectives. To provide a draft RFC which will describe the LPR protocol. To describe printing specific issues on topics currently under discussion within other Working Groups (e.g., Security and Dynamic Host Configuration), to present our concerns to those Working Groups, and to examine printing protocols which exist or are currently under development and assess their applicability to Internet-wide use, suggesting changes if necessary. Internet Drafts: No Current Internet drafts. Office Document Architecture (oda) Charter Chair(s): Peter Kirstein Applications Area Director(s) Brewster Kahle Erik Huizer Mailing lists: General Discussion:ietf-osi-oda@cs.ucl.ac.uk To Subscribe: ietf-osi-oda-request@cs.ucl.ac.uk Archive: Description of Working Group: The ODA Working Group will develop guidelines for the use of the Office Document Architecture for the exchange of Compound documents including formattable text, bit-map graphics and geometric graphics according to the ODA Standard. It will consider also Intercept Standards for other document content types it considers vital - e.g., spreadsheets. The Working Group will define how to use both SMTP and X.400 for interchange of ODA documents. It will maintain close liaison with the SMTP and X.400 Working Groups. This Working Group will review the availability of ODA implementations, in order to mount a Pilot Testbed for processable compound document interchange. Finally, it will set up and evaluate such a testbed. Internet Drafts: No Current Internet drafts. Operational Statistics (opstat) Charter Chair(s): Bernhard Stockman Phillip Gross Operational Requirements Area Director(s) Scott Bradner Bernhard Stockman Mailing lists: General Discussion:oswg-l@wugate.wustl.edu To Subscribe: oswg-l-request@wugate.wustl.edu Archive: wuarchive.wustl.edu:~doc/mailing-lists/oswg-l Description of Working Group: Today there exist a variety of network management tools for the collection and presentation of network statistical data. Different kinds of measurements and presentation techniques makes it hard to compare data between networks. There exists a need to compare these statistical data on a uniform basis to facilitate cooperative management, ease problem isolation and network planning. The Working Group will try to define a model for network statistics, a minimal set of common metrics, tools for gathering statistical data, a common statistical database storage format and common presentation formats. Collecting tools will store data in a given format later to be retrieved by presentation tools displaying the data in a predefined way. Internet Drafts: No Current Internet drafts. OSI Directory Services (osids) Charter Chair(s): Steve Kille Applications Area Director(s) Brewster Kahle Erik Huizer Mailing lists: General Discussion:ietf-osi-ds@cs.ucl.ac.uk To Subscribe: ietf-osi-ds-request@cs.ucl.ac.uk Archive: Description of Working Group: The OSI-DS Group works on issues relating to building an OSI Directory Service using X.500 and its deployment on the Internet. Whilst this Group is not directly concerned with piloting, the focus is practical, and technical work needed as a pre-requisite to deployment of an open Directory will be considered. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 90 Jan 93 Using the OSI Directory to Achieve User Friendly Naming Jan 92 Jan 93 A String Representation of Distinguished Names Apr 92 Jan 93 Lightweight Directory Access Protocol May 92 Aug 92 The String Representation of Standard Attribute Syntaxes Sep 92 New DSA Metrics Open Shortest Path First IGP (ospf) Charter Chair(s): Mike Petry John Moy Routing Area Director(s) Robert Hinden Mailing lists: General Discussion:ospfigp@trantor.umd.edu To Subscribe: ospfigp-request@trantor.umd.edu Archive: Description of Working Group: The OSPF Working Group will develop and field test an SPF-based Internal Gateway Protocol. The specification will be published and written in such a way so as to encourage multiple vendor implementations. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jul 91 Feb 93 OSPF Version 2 Traps Oct 92 New The OSPF NSSA Option Nov 92 New OSPF Version 2 Management Information Base Nov 92 Mar 93 OSPF Version 2 Mar 93 New The OSPF External Attributes LSA Privacy-Enhanced Electronic Mail (pem) Charter Chair(s): Stephen Kent Security Area Director(s) Stephen Crocker Mailing lists: General Discussion:pem-dev@tis.com To Subscribe: pem-dev-request@tis.com Archive: pem-dev-request@tis.com Description of Working Group: PEM is the outgrowth of work by the Privacy and Security Research Group (PSRG) of the IRTF. At the heart of PEM is a set of procedures for transforming RFC 822 messages in such a fashion as to provide integrity, data origin authenticity, and optionally, confidentiality. PEM may be employed with either symmetric or asymmetric cryptographic key distribution mechanisms. Because the asymmetric (public-key) mechanisms are better suited to the large scale, heterogeneously administered environment characteristic of the Internet, to date only those mechanisms have been standardized. The standard form adopted by PEM is largely a profile of the CCITT X.509 (Directory Authentication Framework) recommendation. PEM is defined by a series of documents. The first in the series defines the message processing procedures. The second defines the public-key certification system adopted for use with PEM. The third provides definitions and identifiers for various algorithms used by PEM. The fourth defines message formats and conventions for user registration, Certificate Revocation List (CRL) distribution, etc. (The first three of these were previously issued as RFCs 1113, 1114 and 1115. All documents have been revised and are being issed first as Internet Drafts.) Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 92 Mar 93 MIME-PEM Interaction P. Internet Protocol (pip) Charter Chair(s): Paul Francis Internet Area Director(s) Stev Knowles David Piscitello Mailing lists: General Discussion:pip@thumper.bellcore.com To Subscribe: pip-request@thumper.bellcore.com Archive: thumper.bellcore.com:~/pub/tsuchiya/pip-archive Description of Working Group: The PIP Working Group is chartered to develop an IPv7 proposal using the basic ideas of Pip as described in the Pip overview. Pip is designed on one hand to be very general, being able to handle many routing/addressing/flow paradigms, but on the other hand to allow for relatively fast forwarding. Pip has the potential to allow for better evolution of the internet. In particular, it is hoped that we will be able to advance routing, addressing, and flow techniques without necessarily having to change hosts (once hosts are running Pip). While the Pip overview demonstrates a number of powerful mechanisms, much work remains to be done to bring Pip to a full specification. This work includes, but is not limited to: specifying the header format; specifying a basic set of error messages (PCMP messages); specifying the Pip forwarding rules; specifying host interface messages (particularly the directory service query response); specifying rules for host Pip header construction; specifying modifications to existing protocols for use with Pip (BGP IV, OSPF, ARP, DNS, etc.); specifying Pip MAX MTU Discovery techniques; and specifying a transition strategy for Pip. Over the near-term, the goal of the PIP Working Group will be to produce these specifications and supporting documentation. Over the long-term, up to the point where Pip is definitively rejected as IPv7, it is expected that the PIP Working Group will oversee implementations and testing of the Pip specifications. Except to the extent that the PIP Working Group modifies existing protocols for operation with Pip, and to the extent that the PIP Working Group must be aware of routing/addressing/flow architectures to really make Pip general, the PIP Working Group will not work on routing/addresing/flow architectures. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 92 Feb 93 Pip Header Processing Nov 92 New The EIPIP Protocol: a Pip engine with an EIP shell Nov 92 New Transition to the Future Internet Protocol a comparison of three transition schemes Nov 92 Jan 93 Pip Identifiers Nov 92 New IPv7 Criteria Analysis for EIPIP Jan 93 New Use of DNS with Pip Feb 93 New Pip Near-term Architecture Mar 93 New On the Assignment of Provider Rooted Addresses Apr 93 New The Multi-Level Path Vector Routing Scheme Process for Organization of Internet Standards (poised) Charter Chair(s): Steve Crocker None Director(s) Phill Gross Mailing lists: General Discussion:poised@cnri.reston.va.us To Subscribe: poised-request@cnri.reston.va.us Archive: ietf.cnri.reston.va.us:~/ietf-mail-archive/poised/* Description of Working Group: The goal of this Working Group is to examine the Internet standards process and the responsibilities of the IAB, with attention to the relationship between the IAB and IETF/IESG. The need for this Working Group was suggested during discussions at the July 1992 IETF. This led to a request from the Internet Society president to form such a Working Group. The Working Group will consider the following matters: 1. Procedures for making appointments to the Internet Architecture Board. 2. Procedures for resolving disagreements among IETF, IESG and IAB in matters pertaining to the Internet Standards. 3. Methods for assuring that for any particular Internet Standard, procedures have been followed satisfactorily by all parties so that everyone with an interest has had a fair opportunity to be heard. The Working Group will begin with a review of the procedures for making IAB appointments as documented in RFC 1358 and a review of the standards-making process documented in RFC 1310. The Working Group has a goal of issuing a final report in time for IESG consideration and publication as an RFC before the ISOC Board Trustee's meeting in December 1992. Given the compressed timescale, the Working Group will conduct most of its deliberations by electronic mail on the POISED Working Group mailing list. There will also be a preliminary report and discussions at the November 1992 IETF meeting in Washington, DC. This will be a normal IETF Working Group, i.e., the mailing list and all discussions will be completely open. Internet Drafts: No Current Internet drafts. Point-to-Point Protocol Extensions (pppext) Charter Chair(s): Brian Lloyd Internet Area Director(s) Stev Knowles David Piscitello Mailing lists: General Discussion:ietf-ppp@ucdavis.edu To Subscribe: ietf-ppp-request@ucdavis.edu Archive: Description of Working Group: The Point-to-Point Protocol (PPP) was designed to encapsulate multiple protocols. IP was the only network layer protocol defined in the original documents. The Working Group is defining the use of other network level protocols and options for PPP. The Group will define the use of protocols including: bridging, ISO, DECNET (Phase IV and V), XNS, and others. In addition it will define new PPP options for the existing protocol definitions, such as stronger authentication and encryption methods. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jul 88 Mar 93 Requirements for an Internet Standard Point-to-Point Protocol Jun 92 Oct 92 The PPP Internetwork Packet Exchange Control Protocol (IPXCP) Jun 92 Jul 92 The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol Jun 92 Jul 92 The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol Jun 92 Jul 92 The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol Jun 92 Jul 92 The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol Dec 92 Apr 93 Compressing IPX Headers Over WAN Media (CIPX) Jan 93 Mar 93 PPP LCP Extensions Mar 93 New PPP over ISDN Mar 93 New PPP over X.25 Mar 93 New PPP over Frame Relay Mar 93 New PPP over SONET Router Requirements (rreq) Charter Chair(s): Philip Almquist Internet Area Director(s) Stev Knowles David Piscitello Mailing lists: General Discussion:ietf-rreq@Jessica.Stanford.edu To Subscribe: ietf-rreq-request@Jessica.Stanford.edu Archive: Description of Working Group: The Router Requirements Working Group has the goal of rewriting the existing Router Requirements RFC, RFC-1009, and a) bringing it up to the organizational and requirement explicitness levels of the Host Requirements RFC's, as well as b) including references to more recent work, such as OSPF and BGP. The Working Group will also instigate, review, or (if appropriate) produce additional RFCs on related topics. To date, Group members have produced draft documents discussing the operation of routers which are in multiple routing domains (3 papers), TOS, and a routing table MIB. The purposes of this project include: - Defining what an IP router does in sufficient detail that routers from different vendors are truly interoperable. - Providing guidance to vendors, implementors, and purchasers of IP routers. The Working Group has decided that, unlike RFC-1009, the Router Requirements document should not discuss Link Layer protocols or address resolution. Instead, those topics should be covered in a separate Link Layer Requirements document, applicable to hosts as well as routers. Whether this Group will create the Link Layer Requirements is still to be determined. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Sep 90 Mar 93 Requirements for IP Routers Volume 1: Introduction Source Demand Routing (sdr) Charter Chair(s): Deborah Estrin Tony Li Routing Area Director(s) Robert Hinden Mailing lists: General Discussion:sdrp@caldera.usc.edu To Subscribe: sdrp-request@caldera.usc.edu Archive: jerico.usc.edu:~/pub/sdrp Description of Working Group: The SDR Working Group is chartered to specify and promote the use of SDR (Source Demand Routing Protocol) as an interdomain routing protocol capability in conjunction with IDRP and BGP interdomain routing protocols. The purpose of SDR is to support source-initiated selection of interdomain routes, to complement the intermediate node selection provided by BGP/IDRP. The goal of the SDR working group is to release the components of SDR as IETF Prototypes and to obtain operational experience with SDR in the Internet. Once there is enough experience with SDR the working group will submit the SDR components to the IESG for standardization. SDR has four components: Packet formats for protocol control messages and encapsulation of user datagrams, Processing and forwarding of user data and control messages, Routing information distribution/collection and route computation, Configuration and usage. Our strategy is to: 1. Define the format, processing and forwarding of user datagram and control messages so that SDR can be used very early on as an efficient means of supporting "configured" inter-domain routes. User packets are encapsulated along with the source route and forwarded along the "configured" route. Routes are static at the inter-domain level, but are not static in terms of the intra-domain paths that packets will take between specified points in the SDR route. The impact of encapsulation on MTU, ICMP, performance, etc., are among the issues that must be evaluated before deployment. 2. Develop simple schemes for a) collecting dynamic domain-level connectivity information, and b) route construction based on this information, so that those domains that want to can make use of a richer, and dynamic set of SDR routes. 3. In parallel with 1 and 2, develop usage and configuration documents and prototypes that demonstrate the utility of static-SDR and simple-dynamic-SDR. 4. After gaining some experience with the simple schemes for distribution, develop a second generation of information distribution and route construction schemes. We hope to benefit from discussions with IDPR and NIMROD developers at this future stage because the issues faced are similar. 5. We will also investigate the addition of security options into the SDRP forwarding and packet format specifications. Internet Drafts: No Current Internet drafts. Simple Internet Protocol (sip) Charter Chair(s): Christian Huitema Steve Deering Internet Area Director(s) Stev Knowles David Piscitello Mailing lists: General Discussion:sip@caldera.usc.edu To Subscribe: sip-request@caldera.usc.edu Archive: Description of Working Group: SIP is another candidate for IPv7. The purpose of the Working Group is to finalize the SIP family of protocol, and to foster the early development and experimentation of this protocol. There are two major characteristics of the SIP proposal: it is very much a continuation of IP, and it aims at maximum simplicity. A short hand definition of SIP could be ``64 bits IP with useless overhead removed''. Following the IP model, SIP uses globally-unique addresses, hierarchically structured for efficient routing. SIP addresses are 64 bits long, which we believe adequate to scale the Internet up to, say, thousands of internet-addressable devices in every office, every residence, and every vehicle in the world. The quest of simplicity in SIP has been described as parallel to the RISC philosophy. The minimal SIP header contains only those fields which are necessary to achieve our goal: routing packets efficently in a very large internet. As a result of this design philosophy, the SIP header is much simpler than the IP header. Simplicity facilitates high-performance implementation and increases the likelihood of correct implementation. Contrary to several other IPv7 candidates, the SIP effort is focused mostly on the description of the final state, not on the description of the transition. This is due to a coordination with the IPAE working group, which has already engaged an intensive study of transition problems, with SIP in mind as a final state. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 92 New Simple Internet Protocol (SIP) Specification Mar 93 New SIP-RIP Apr 93 New SIP Program Interfaces for BSD Systems SNMP Security (snmpsec) Charter Chair(s): James Galvin Keith McCloghrie Security Area Director(s) Stephen Crocker Mailing lists: General Discussion:snmp-sec-dev@tis.com To Subscribe: snmp-sec-dev-request@tis.com Archive: snmp-sec-dev-request@tis.com Description of Working Group: Enhancements to the SNMP network management framework are being contemplated within the SNMP Version 2 Working Group of the IETF. The SNMP Security Working Group is chartered to consider changes to RFCs 1351, 1352, 1353 that may be required either for consistency with this SNMP evolution effort or to reflect implementation experience with the current specifications. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Dec 92 Mar 93 Party MIB for version 2 of the Simple Network Management Protocol (SNMPv2) Dec 92 Mar 93 Administrative Model for version 2 of the Simple Network Management Protocol (SNMPv2) Dec 92 Mar 93 Security Protocols for version 2 of the Simple Network Management Protocol (SNMPv2) SNMP Version 2 (snmpv2) Charter Chair(s): Bob Stewart Network Management Area Director(s) Marshall Rose Mailing lists: General Discussion:snmp2@thumper.bellcore.com To Subscribe: snmp2-request@thumper.bellcore.com Archive: thumper.bellcore.com:~/pub/davin/snmp2-archive Description of Working Group: This Working Group is chartered to consider technical contributions to the SNMP evolution process and to produce a single recommendation as to which contributions (or combinations or modifications thereof) should define the next generation SNMP network management framework. The announced deadline for technical contributions to the SNMP evolution process is September 10, 1992. Any individual interested in contributing to this process should prepare and submit his/her contribution according to the requirements for detail, completeness, copyright, and format set forth in the original announcement. This Working Group is under no obligation to consider contributions that do not meet these basic requirements or contributions that are not submitted by the contribution deadline. This Working Group has the option of (a) rejecting any or all contributions as the basis for positive evolution, (b) accepting any or all contributions as candidates for standardization, or (c) modifying or combining any or all contributions to produce consensus proposals for standardization. The product of the Working Group will be a single recommendation to the IESG identifying those submitted specifications (or modifications thereof), if any, whose standardization as part of the SNMP framework is agreed to be warranted and desirable. The Working Group will not be chartered to produce tutorial, explanatory, advisory, or informational documents of any kind. In its deliberations, the Working Group will take special cognizance of architectural principles on which the historic success of SNMP has rested: (1) The SNMP framework minimizes the overall cost of a manageable network by minimizing the cost and complexity of those management system components that are most numerous. (2) The SNMP framework fosters ubiquity of deployment by admitting the widest possible range of implementation strategies. (3) The SNMP framework fosters operational robustness by realizing management system function as closely as possible to centers of responsible authority. (4) The SNMP framework fosters operational robustness by locating control of resources consumed by the management activity (e.g., bandwidth, processing) as closely as possible to centers of responsible authority. Moreover, the deliberations of the Working Group will take special cognizance of at least two aspects of evolutionary logistics: (1) A single transition from existing SNMP technology to the next stage of SNMP evolution is highly desirable; multi-stage or protracted transitions are less desirable. (2) Minimizing the number of distinct management technologies concurrently deployed in the Internet is highly desirable. Consistent with the community desire for timely, deliberate progress, the Working Group may be disbanded at the time of the IETF plenary meeting in the Spring of 1993 regardless of whether or not it has produced the single recommendation required by its Charter. This Working Group is not chartered to consider security aspects of the SNMP framework, as these are addressed as a matter of course by an existing IETF working group. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jul 92 Mar 93 Transport Mappings for version 2 of the Simple Network Management Protocol (SNMPv2) Jul 92 Mar 93 Coexistence between version 1 and version 2 of the Network Management Framework Jul 92 Mar 93 Textual Conventions for version 2 of the Simple Network Management Protocol (SNMPv2) Jul 92 Mar 93 Structure of Management Information for version 2 of the Simple Network Management Protocol (SNMPv2) Jul 92 Mar 93 Introduction to version 2 of the Internet-standard Network Management Framework Jul 92 Mar 93 Protocol Operations for version 2 of the Simple Network Management Protocol (SNMPv2) Jul 92 Mar 93 Manager to Manager Management Information Base Jul 92 Mar 93 Management Information Base for version 2 of the Simple Network Management Protocol (SNMPv2) Nov 92 Mar 93 Conformance Statements for version 2 of the Simple Network Management Protocol (SNMPv2) Service Location Protocol (svrloc) Charter Chair(s): John Veizades Scott Kaplan Service Applications Area Director(s) Dave Crocker Mailing lists: General Discussion:srv-location@apple.com To Subscribe: srv-location-request@apple.com Archive: apple.com:~/pub/srv-location/svr-loc-archive Description of Working Group: The Service Location Working Group is chartered to investigate protocols to find and bind to service entities in a distributed internetworked environment. Issues that must be addressed are how such a protocol would interoperate with existing directory based services location protocols. Protocols that would be designed by this Group would be viewed as an adjunct to directory service protocols. These protocols would be able to provide a bridge between directory services and current schemes for service location. The nature of the services location problem is investigative in principle. There is no mandate that a protocol should be drafted as part of this process. It is the mandate of this Group to understand the operation of services location and then determine the correct action in their view whether it be to use current protocols to suggest a services location architecture or to design a new protocol to compliment current architectures. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 93 New Resource Location Protocol TCP Large Windows (tcplw) Charter Chair(s): David Borman Transport Area Director(s) Allison Mankin Mailing lists: General Discussion:tcplw@cray.com To Subscribe: tcplw-request@cray.com Archive: Description of Working Group: The TCP Large Windows Working Group is chartered to produce a specification for the use of TCP on high delay, high bandwidth paths. To this end, this Working Group recommended RFC 1072 ``TCP extensions for long-delay paths'' and RFC 1185 ``TCP Extension for High-Speed Paths'' be published jointly as a Proposed Standard. Deficiencies in the technical details of the documents were identified by the End-to-End Research Group of the IRTF. Rather than progress the standard with known deficiencies, the IESG tasked the End-to-End Research Group to fix and merge these two documents into a single protocol specification document. This review was done on the eze-interest@isi.edu mailing list. The TCP Large Windows Working Group is being resurrected for a one time meeting, to review and if appropriate, approve this new document. Internet Drafts: No Current Internet drafts. TELNET (telnet) Charter Chair(s): Steve Alexander Applications Area Director(s) Brewster Kahle Erik Huizer Mailing lists: General Discussion:telnet-ietf@cray.com To Subscribe: telnet-ietf-request@cray.com Archive: Description of Working Group: The TELNET Working Group will examine RFC 854, ``Telnet Protocol Specification'', in light of the last six years of technical advancements, and will determine if it is still accurate with how the TELNET protocol is being used today. This Group will also look at all the TELNET options, and decide which are still germane to current day implementations of the TELNET protocol. (1) Re-issue RFC 854 to reflect current knowledge and usage of the TELNET protocol. (2) Create RFCs for new TELNET options to clarify or fill in any missing voids in the current option set. Specifically: - Environment variable passing - Authentication - Encryption - Compression (3) Act as a clearing-house for all proposed RFCs that deal with the TELNET protocol. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Apr 90 Apr 93 Telnet Authentication and Encryption Option Apr 93 Apr 93 Telnet Environment Option Apr 93 New Telnet Environment Option Interoperability Issues Minimal OSI Upper-Layers (thinosi) Charter Chair(s): Peter Furniss Applications Area Director(s) Brewster Kahle Erik Huizer Mailing lists: General Discussion:thinosi@ulcc.ac.uk To Subscribe: thinosi-request@ulcc.ac.uk Archive: pluto.ulcc.ac.uk:/ulcc/thinosi/thinosi-mail-archive.txt Description of Working Group: The OSI upper-layer protocols (above Transport) are rich in function and specified in large, complex and numerous documents. However, in supporting a particular application, the protocol actually used is only a subset of the whole. An implementation is not required to support features it never uses, and it is or should be possible to have relatively lightweight implementations specialized for a particular application or group of applications with similar requirements. The application protocol could be an OSI application-layer standards or a protocol originally defined for TCP/IP or other environment. It will be easier to produce such implementations if the necessary protocol is described concisely in a single document. An implementation based on this principle, of the mapping of X Window System protocol over OSI upper-layers exists. The Working Group is chartered to produce two documents ``Skinny bits for byte-stream'' a specification of the bit (octet) sequences that implement the OSI upper-layer protocols (Session, Presentation and ACSE) as needed to support an application that requires simple connection, and byte-stream read and write. This will be based on the octet sequences needed to support X. This will not be expected to be provide a full equivalent of TCP, nor to cover specific standardized protocols. ``Skinny bits for Directory'' a specification of the bit sequences needed for the Directory Access Protocol - in the same style as a), but to include DAP. The level of functionality of this is to be determined. An important aspect of the Group's work is find out if it is possible to produce useful and concise specification of this kind. A minor part is to think of better names. The Group will also encourage the deployment of X/osi implementations and interworking experiments with it. Internet Drafts: No Current Internet drafts. Trusted Network File Systems (tnfs) Charter Chair(s): Fred Glover Service Applications Area Director(s) Dave Crocker Mailing lists: General Discussion:tnfs@wdl1.wdl.loral.com To Subscribe: tnfs-request@wdl1.wdl.loral.com Archive: archive-server@wdl1.wdl.loral.com Description of Working Group: The Trusted Network File System Working Group is chartered to define protocol extensions to the Network File System (NFS) Version 2 protocol which support network file access in a Multilevel Secure (MLS) Internet environment. MLS functionality includes Mandatory Access Control (MAC), Discretionary Access Control (DAC), authentication, auditing, documentation, and other items as identified in the Trusted Computer System Evaluation Criteria (TCSEC) and Compartmented Mode Workstation (CMW) documents. The primary objective of this Working Group is to specify extensions to the NFS V2 protocol which support network file access between MLS systems. It is intended that these extensions should introduce only a minimal impact on the existing NFS V2 environment, and that unmodified NFS V2 clients and servers will continue to be fully supported. Transferring information between MLS systems requires exchanging additional security information along with the file data. The general approach to be used in extending the NFS V2 protocol is to transport additional user context in the form of an extended NFS UNIX style credential between a Trusted NFS (TNFS) client and server, and to map that context into the appropriate server security policies which address file access. In addition, file security attributes are to be returned with each TNFS procedure call. Otherwise, the NFS V2 protocol remains essentially unchanged. The Trusted System Interoperability Group (TSIG) has already developed a specification which defines a set of MLS extensions for NFS V2, and has also planned for the future integration of Kerberos as the authentication mechanism. The TNFS Working Group should be able to use the TSIG Trusted NFS document as a foundation, and to complete the IETF TNFS specification within the next 3-6 months. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Jul 91 Mar 93 A Specification of Trusted NFS (TNFS) Protocol Extensions Token Ring Remote Monitoring (trmon) Charter Chair(s): Michael Erlinger Network Management Area Director(s) Marshall Rose Mailing lists: General Discussion:rmonmib@lexcel.com To Subscribe: rmonmib-request@lexcel.com Archive: Description of Working Group: The Token Ring Remote Monitoring MIB Working Group is chartered to produce a new MIB specification that extends the facilities of the existing Remote Monitoring (RMON) MIB (RFC 1271) for use in monitoring IEEE 802.5 Token Ring networks. The Token Ring RMON MIB extensions will be developed in the same architectural framework as the existing Ethernet-based RMON MIB. The original RMON MIB architecture was designed with the intention of incorporating MIB extensions devoted to monitoring other network media types. This Token Ring activity is the first attempt at such integration. In creating the Token Ring Extensions the Working Group will, wherever possible, conform to terminology and concepts defined by relevant IEEE standards. It may be that a MIB devoted to monitoring may need to expand on the IEEE objects and definitions. Such modifications will be accompanied by a detailed rationale. All work produced by the Token Ring Remote Monitoring Working Group will be consistent with the existing SNMP network management framework and standards. Internet Drafts: No Current Internet drafts. TCP/UDP over CLNP-addressed Networks (tuba) Charter Chair(s): Mark Knopper Peter Ford Internet Area Director(s) Stev Knowles David Piscitello Mailing lists: General Discussion:tuba@lanl.gov To Subscribe: tuba-request@lanl.gov Archive: Description of Working Group: The TUBA Working Group will work on extending the Internet Protocol suite and architecture by increasing the number of end systems which can be effectively addressed and routed. The TUBA effort will expand the ability to route Internet packets by using addresses which support more hierarchy than the current Internet Protocol (IP) address space. TUBA specifies the continued use of Internet Transport Protocols, in particular TCP and UDP, but encapsulated in ISO 8473 (CLNP) packets. This will allow the continued use of Internet application protocols such as FTP, SMTP, Telnet, etc. An enhancement to the current system is mandatory due to the limitations of the current 32 bit IP addresses. TUBA seeks to upgrade the current system by a transition from the use of the Internet Protocol version 4 to ISO/IEC 8473 (CLNP) and the corresponding large Network Service Access Point address space. In addition to protocol layering issues and ``proof of concept'' work, the TUBA approach will place significant emphasis on the engineering and operational requirements of a large, global, multilateral public data network. TUBA will work to maximize interoperatability with the routing and addressing architecture of the global CLNP infrastructure. The TUBA Working Group will work closely with the IETF NOOP and IPRP-for-IP Working Groups to coordinate a viable CLNP based Internet which supports the applications which Internet users depend on such as Telnet, FTP, SMTP, NFS, X, etc. The TUBA Working Group will also work collaboratively with communities which are also using the CLNP protocol, and will consider issues such as interoperability, applications coexisting on top of multiple transports, and the evolution of global public connectionless datagram networks, network management and instrumentation using CLNP and TUBA, and impact on routing architecture and protocols given the TUBA transition. The TUBA Working Group will consider how the TUBA scheme will support transition from the current IP address space to the future NSAP address space without discontinuity of service, although different manufacturers, service providers, and sites will make the transition at different times. In particular, the way in which implementations relying on current 32 bit IP addresses will migrate must be considered. TUBA will ensure that IP addresses can be assigned, for as long as they are used, independently of geographical and routing considerations. One option is to embed IP addresses in NSAP addresses, possibly as the NSAP end-system identifier. Whatever scheme is chosen must run in a majority of *-GOSIPs and other NSAP spaces. The TUBA strategy will require a new mapping in the DNS from NAMEs to NSAP addresses. The rationale RFC (RFC-1347) documents issues of transition and coexistence, among unmodified ``IP'' hosts and hosts which support ``TUBA'' hosts. Hosts wishing full Internet connectivity will need to support TUBA. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Sep 92 Jan 93 Use of ISO CLNP in TUBA Environments Nov 92 New Addressing and End Point Identification, For Use with TUBA User Connectivity (ucp) Charter Chair(s): Dan Long Operational Requirements Area Director(s) Scott Bradner Bernhard Stockman Mailing lists: General Discussion:ucp@nic.near.net To Subscribe: ucp-request@nic.near.net Archive: Description of Working Group: The User Connectivity Working Group will study the problem of how to solve network users' end-to-end connectivity problems. Internet Drafts: No Current Internet drafts. Uninterruptible Power Supply (upsmib) Charter Chair(s): Jeff Case Network Management Area Director(s) Marshall Rose Mailing lists: General Discussion:ups-mib@cs.utk.edu To Subscribe: ups-mib-request@cs.utk.edu Archive: ucs.utk.edu:~/pub/ups-mib/mail-archive Description of Working Group: This Working Group will produce a document that defines MIB objects for use in monitoring and (possibly) control of both high-end and low-end UPSs and related systems (e.g., power distribution systems or power conditioning systems). Related devices may be addressed in this effort to the extent that the primary focus on UPSs is not compromised. The MIB object definitions produced will be for use by SNMP and will be consistent with existing SNMP standards and framework. At its discretion, the Working Group may fulfill its Charter by the development of distinct MIB definitions for UPS systems of differing capabilities, but the number of MIB definitions produced by the Working Group will not exceed two. At its discretion, the Working Group may produce an additional document defining traps that support the management of UPSs. Although the Working Group may choose to solicit input or expertise from other relevant standards bodies, no extant standards efforts or authorities are known with which alignment of this work is required. Because the structure of UPS implementations varies widely, the working group shall take special care that its definitions reflect a generic and consistent architectural model of UPS management rather than the structure of particular UPS implementations. Internet Drafts: No Current Internet drafts. Uniform Resource Identifiers (uri) Charter Chair(s): Jim Fullton Alan Emtage User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:uri@bunyip.com To Subscribe: uri-request@bunyip.com Archive: archives.cc.mcgill.ca:~/pub/uri-archive Description of Working Group: The Uniform Resource Identifiers Archives Working Group is chartered to define a set of standards for the encoding of system independent Resource Location and Identification information for the use of Internet information services. This Working Group is expected to produce a set of documents that will specify standardized representations of Uniform Resource Locators (URLs) which specify a standardized method for encoding location and access information across multiple information systems. Such standards are expected to build upon the document discussed at the UDI BOF session held during the 24th IETF meeting in Boston, Unique Resource Serial Numbers (URSNs) which specify a standardized method for encoding unique resource identification information for Internet resources and Uniform Resource Identifiers (URIs), which specify a standardized method for encoding combined resource identification and location information systems to be used for resource discovery and access systems in an Internet environment. Such a set of standards will provide a framework that: allows the Internet user to specify the location and access information for files and other resources on the Internet, allows users and network-based tools to uniquely identify specific resources on the Internet, and allows the creation and operation of resource discovery and access systems for the Internet. The security of such resource discovery services will also be considered to be an integral part of the work of this Group. Internet Drafts: No Current Internet drafts. User Services (uswg) Charter Chair(s): Joyce K. Reynolds User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:us-wg@nnsc.nsf.net To Subscribe: us-wg-request@nnsc.nsf.net Archive: nnsc.nsf.net:~/nsfnet/us-wg* Description of Working Group: The User Services Working Group provides a regular forum for people interested in user services to identify and initiate projects designed to improve the quality of information available to end-users of the Internet. (Note that the actual projects themselves will be handled by separate groups, such as IETF working groups created to perform certain projects, or outside organizations such as SIGUCCS. (1) Meet on a regular basis to consider projects designed to improve services to end-users. In general, projects should: - Clearly address user assistance needs; - Produce an end-result (e.g., a document, a program plan, etc.); - Have a reasonably clear approach to achieving the end-result (with an estimated time for completion); - Not duplicate existing or previous efforts. (2) Create working groups or other focus groups to carry out projects deemed worthy of pursuing. (3) Provide a forum in which user services providers can discuss and identify common concerns. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Apr 93 New FYI on "What is the Internet?" Whois and Network Information Lookup Service (wnils) Charter Chair(s): Joan Gargano User Services Area Director(s) Joyce Reynolds Mailing lists: General Discussion:ietf-wnils@ucdavis.edu To Subscribe: ietf-wnils-request@ucdavis.edu Archive: ucdavis.edu:~/pub/ietf-wnils-archive Description of Working Group: The Network Information Center (NIC) maintains the central NICNAME database and server, defined in RFC 954, providing online look-up of individuals, network organizations, key nodes, and other information of interest to those who use the Internet. Other distributed directory information servers and information retrieval tools have been developed and it is anticipated more will be created. Many sites now maintain local directory servers with information about individuals, departments and services at that specific site. Typically these directory servers are network accessible. Because these servers are local, there are now wide variations in the type of data stored, access methods, search schemes, and user interfaces. The purpose of the Whois and Network Information Lookup Service (WNILS) Working Group is to expand and define the standard for WHOIS services, to resolve issues associated with the variations in access and to promote a consistent and predictable service across the network. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Nov 92 Apr 93 Architecture of the Whois++ Index Service X.25 Management Information Base (x25mib) Charter Chair(s): Dean Throop Network Management Area Director(s) Marshall Rose Mailing lists: General Discussion:x25mib@dg-rtp.dg.com To Subscribe: x25mib-request@dg-rtp.dg.com Archive: dg-rtp.dg.com:~/x25mib/Current.Mail Description of Working Group: This Working Group will produce a set of three documents that describe the Management Information Base for X.25. The first document will specify the objects for the X.25 Link Layer. The second document will specify the objects for the X.25 Packet Layer. The third document will specify the objects for managing IP over X.25. The Working Group need not consider the Physical Layer because the ``Definition of Managed Objects for RS-232-like Hardware Devices'' already defines sufficient objects for the Physical Layer of a traditional X.25 stack. Any changes needed at the Physical Layer will be addressed as part of that activity. The X.25 object definitions will be based on ISO documents 7776 and 8208 however nothing should preclude their use on other similar or interoperable protocols (i.e., implementations based on CCITT specifications). The objects in the Link and Packet Layer documents, along with the RS-232-like document, should work together to define the objects necessary to manage a traditional X.25 stack. These objects will be independent of any client using the X.25 service. Both of these documents assume the interface table as defined in MIB-II contains entries for the Link and Packet Layer interfaces. Thus these documents will define tables of media specific objects which will have a one to one mapping with interfaces of ifType ddn-x25, rfc877-x25, or lapb. The objects for the IP to X.25 convergence functions will be defined analogously with the ipNetToMedia objects in MIB II. The Working Group will endeavor to make each layer independent from other layers. The Link Layer will be independent of any Packet Layer protocol above it and should be capable of managing an ISO 7776 (or similar) Link Layer provider serving any client. Likewise the X.25 Packet Layer objects should be independent of the Link Layer below it and should be capable of managing an ISO 8208 (or similar) Packet Layer serving any client. The Working Group will also produce a third document specifying the objects for managing IP traffic over X.25. These objects will reside in their own table but will be associated with the X.25 interfaces used by IP. These objects will not address policy decisions or other implementation specific operations associated with X.25 connection management decisions except as explicitly described in existing standards. These objects will manage the packet flow between IP and the X.25 Packet Layer specifically including observation of packet routing and diagnosis of error conditions. Progress on the Link and Packet Layer documents will not depend on progress of the IP over X.25 document. The IP over X.25 document will proceed on a time available basis after work on the Link and Packet Layer documents and as such the Link and Packet Layers may be completed before the IP over X.25 work. All documents produced will be for use by SNMP and will be consistent with other SNMP objects, conventions, and definitions (such as Concise MIB format). To the extent feasible, the object definitions will be consistent with other network management definitions. In particular ISO/IEC CD 10733 will be considered when defining the objects for the X.25 Packet Layer. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Oct 91 Jan 93 SNMP MIB extension for MultiProtocol Interconnect over X.25 X.400 Operations (x400ops) Charter Chair(s): Alf Hansen Tony Genovese Applications Area Director(s) Brewster Kahle Erik Huizer Mailing lists: General Discussion:ietf-osi-x400ops@cs.wisc.edu To Subscribe: ietf-osi-x400ops-request@cs.wisc.edu Archive: Description of Working Group: X.400 management domains are being deployed today on the Internet. There is a need for coordination of the various efforts to insure that they can interoperate and collectively provide an Internet-wide X.400 message transfer service connected to the existing Internet mail service. The overall goal of this Group is to insure interoperability between Internet X.400 management domains and the existing Internet mail service. The specific task of this Group is to produce a document that specifies the requirements and conventions of operational Internet PRMDs. Internet Drafts: Posted Revised I-D Title ------ ------- ------------------------------------------ Mar 92 Mar 93 Routing coordination for X.400 MHS services within a multi protocol / multi network environment Table Format V3 for static routing Mar 92 Mar 93 Operational Requirements for X.400 Management Domains in the GO-MHS Community Jun 92 Mar 93 X.400 use of extended character sets Nov 92 Mar 93 Postmaster Convention for X.400 Operations Dec 92 Jan 93 Assertion of C=US; A=IMX Jan 93 Jan 93 Using the Internet DNS to maintain RFC1327 Address Mapping Tables Feb 93 Mar 93 Using the Internet DNS to maintain X.400 MHS Routing Informations Feb 93 New Evaluation of ADMDs and Integration aspects with respect to the R&D messaging community Mar 93 New Table distribution